During execution of a computer program, objects are allocated memory to store information. In many environments, memory management routines are provided to enable programmers to dynamically allocate and deallocate memory for objects during the execution of the program. The area of memory from which objects are dynamically allocated and reallocated is often referred to as a “heap.” In some run-time environments, e.g. in a JAVA™ virtual machine, the memory management routines also provide for garbage collection, which automatically reclaims memory for objects that are no longer used, so that the reclaimed memory is available for subsequently allocating other objects.
Generally, a garbage collector determines whether an object is no longer used and can therefore recycle the object's memory when the object is no longer referenced within the program. However, some user programs in garbage-collected, run-time environments unintentionally keep references to objects that are no longer going to used in the program, thereby consuming large amounts of memory because keeping a reference to an object prevents the garbage collector from identifying the object as garbage and reclaiming that object's memory. If the program eventually requests to use more memory from the heap than what is available, the program runs out of memory, typically crashing or otherwise failing to perform its intended function.
Debugging the application programming errors that lead to running out of heap memory is a difficult process. Typically, such debugging involves analyzing which objects reference which other objects. Conventional techniques, however, for analyzing the referencing relationships of user-created objects to determine why programs run out of memory are cumbersome and slow. One approach to analyzing these relationships is by running a tool in the virtual machine itself that would analyze the heap in the virtual machine and provide a digest of the memory allocation, e.g. how much memory is retained by which objects, but often these digests can be so large that it is difficult for a developer to manually wade through. In particular, developers may have complicated data structures but previous tools provide limited means for accessing and printing out information concerning the objects in the heap.
Therefore, there is a need for method for analyzing a heap for memory errors, particularly that assists developers in understanding the structure and relationships of objects found in a heap that was dumped in low-memory situations.